Christopher James Huff wrote:
> In article <pan### [at] NOSPAMml1net>,
>  Tyler Eaves <tyl### [at] NOSPAMml1net> wrote:
>>8. A C(++) API
>>    This is another way of acheiving some of the above speed-related 
>>    goals. Allowing creating a pov-scene by linking against the API,
>>    giving code that builds a binary to render the scene. The ultimate
>>    for CPU intensive stuff.
> 
> 
> Not practical. There is no standard way of loading object code on 
> different platforms, and the code itself would have to be compiled for 
> the platform the scene is to be rendered on. Including a compiler along 
> with POV would be a lot of effort, and distributing precompiled code 
> would create compatibility problems.

You know this one as always bugged me, the whole not practical thing.

For a guess the library author would have a compiler and it only takes
on willing person per platform to compile it for others. So that not to 
much of a problem really. The lack of a complier would only effect
people want to use a libraries features for a platform that one one has 
complied it for which is no different to those who want to use a 
Unofficial version of Pov in the same scenario.

The object code loading thing. Yes there is no standard way to do this, 
so you create one. All You'd need to do is pull back a C++ object so it 
does not need to be to complex does everything dlopen can do API. Simply 
wrap dlopen and LoadLibrary and that would cover Linux, Mac OSX and 
Windows.
something like

#define dsoOpen(x) dlopen(x, RTLD_NOW);
#define dsoGetSymbol(x,y) dlsym(x, y)
#define dsoError()  dlerror()
#define dsoClose(x)  dlclose(x)

and windows ...

#define dsoOpen(x) LoadLibrary(x)
#define dsoGetSymbol(x,y) GetProcAddress((HINSTANCE )x, y)
#define dsoError()  GetLastError()
#define dsoClose(x)  FreeLibrary(x)

If anything more fancy is required for other OS's then that
platform's dso* code become actual functions. The Mac
version could use the CFBundles? stuff directly for example.


The library exports functions that return a new instance
of a class, which inherits from a predefined povray class.
You could have a povFunction classes which return a float,
povPigment classes that return rgbft etc or one class which
has evaluateAsFloat, evaluateAsPigment etc methods

void *perlins_noise(void){
     return new myPerlinFunctionClass();
}

There will need to be extensions to SDL to..

Load the library,
Identify the class required and its type if there are different classes 
     for different functionality,
Pass the parameters to a 'setParmaters' method. Perhaps something like a 
color_map using keyed pairs.

dso {
  function
  "/path/to/library"
  "perlins_noise"
  parameter_map {
    ["octaves" 6]
    ["frequency 2.0]
  }
}

All the code is from memory so I may have got the function names or 
usage wrong, but I can't see why it wouldn't work from a technical point 
of view.

Dave

Post a reply to this message